Lastenheft

ACHTUNG! Lastenheft fürs Review nicht mehr änderbar! Inhalt am 27.04.2011 20:13 Uhr fürs Review kopiert!!

Dokumentenhistorie

1 Einleitung

Im Rahmen des Verbundstudiums ist im Modul Fortgeschrittene Softwaretechnologie die Durchführung eines eigenständigen Softwareprojekts in Projektteams von 3-5 Mitgliedern vorgesehen. In diesem Zusammenhang hat sich diese Projektgruppe bestehend aus den Projektmitgliedern Andrea Höpfner, Marcel Menze, Oliver Webersberger, Sebastian Wehmeyer und Aleksandar Dimitrov das Ziel gesetzt eine Anwendung zu entwickeln, die es ermöglicht spontane Fahrgemeinschaften zu bilden.
Zur Anforderungsaufnahme dient dieses Lastenheft, das die Rahmenbedingungen für die Entwicklung festgelegt. Diese werden in der Gesamtsystemspezifikation –dem Pflichtenheft- detailliert beschrieben. Kern des Lastenhefts sind die funktionalen und nichtfunktionalen Anforderungen an das System, sowie eine Skizze des Gesamtsystementwurfs.

2 Ausgangssituation, Zielbestimmung und Stakeholder

2.1 Ausgangssituation

Zurzeit werden Mitfahrgelegenheiten durch Anbieter wie die Mitfahrzentrale angeboten. Diese bieten die Möglichkeit vor Beginn einer Reise eine Fahrgemeinschaft zu bilden. Um eine Fahrgemeinschaft zu bilden ist vorab eine Anmeldung am jeweiligen System des Anbieters über die entsprechende Internetseite notwendig. Um den Wettlauf um Mobile Endgeräte wie Smartphones nicht zu verlieren, werden Applikationen von den einzelnen Anbietern der Mitfahrgelegenheiten angeboten, die die Betriebssysteme iOS und Android ebenfalls unterstützen.
Der Nachteil der bestehenden Systeme besteht in der fehlenden Anbindung an Soziale Netzwerke, die immer stärker an Beliebtheit und neue Mitglieder gewinnen. Darüber hinaus sind spontane Reisen nicht möglich, da Reisen stets in das System eingegeben werden müssen, um von potentiellen Mitfahrern dort gebucht werden zu können. Die bestehenden Systeme der Mitfahrgelegenheitanbieter stellen keine Möglichkeiten zur Verfügung, um spontane Reisen anzutreten.
Diese Lücke soll die zu entwickelnde Anwendung schließen. Mitglieder von Sozialen Netzwerken wie Facebook können die Anwendung ebenso nutzen, wie Personen, die ein Profil am neuen System erstellen. Weiterhin können Anwender spontane Fahrten in das System eingeben, die durch speziell hierfür zu entwickelnde Maßnahmen an die weiteren Mitglieder weitergeleitet werden, damit diese ebenso spontan an Fahrten als Mitfahrer teilnehmen können. Der Vorteil für Fahrer und Mitfahrer ist, dass die Kosten der Reise aufgeteilt werden können. Für Personen ohne eigenes Fahrzeug ist dies als Alternative zu öffentlichen Verkehrsmitteln zu sehen.

2.2 Zielbestimmung

Die Anwendung soll Fahrer und potentielle Mitfahrer zueinander bringen um eine Fahrgemeinschaft zu bilden, wenn ein ähnlicher Fahrtwunsch vorliegt.
Aus Sicht des Fahrtanbieters soll die zu entwickelnde Anwendung Mitfahrer mit ähnlichem Start und Ziel anzeigen. Potentielle Mitfahrer, deren Startpunkt in der Nähe der zurückzulegenden Strecke liegen, sollen dem Fahrtanbieter ebenfalls präsentiert werden. Auch nach Fahrtantritt sollen dem Fahrtanbieter potentielle Mitfahrer mit ähnlichem Ziel übermittelt werden, deren Startort in der Nähe der aktuellen Position des Fahrtanbieters liegt. Dem Fahrer werden die freigegebenen Profilinformationen und bisherigen Bewertungen des potentiellen Mitfahrers angezeigt. Entscheidet der Fahrer, dass er einen Mitfahrer mitnehmen möchte, so muss die Anwendung dem Fahrer die Kontaktinformationen des Fahrtsuchenden anzeigen. Die Kontaktaufnahme und die Verhandlung über das Kostenteilen muss von der Anwendung nicht unterstützt werden.
Aus Sicht der Mitfahrer soll das Reisegesuch im Voraus oder spontan angegeben werden können. Die Anwendung soll dem Mitfahrer alle zu seinem Mitfahrwunsch passenden Fahrtangebote anzeigen. Der Mitfahrer wählt unter den ermittelten Fahrtangeboten aus. Auch dem Mitfahrer sollen die freigegebenen Profilinformationen und die bisherigen Bewertungen des Fahrers angezeigt werden können. Damit eine Kontaktaufnahme möglich ist, muss die Anwendung dem Mitfahrer die Kontaktinformationen des Fahrers anzeigen.
Die Anwendung soll es den Teilnehmern ermöglichen Informationen zur Person und in einem eigenen Profil zu pflegen. Fahrer sollen Informationen zu Ihrem Fahrzeug in der Anwendung hinterlegen können.
Kommt eine Fahrgemeinschaft zu Stande, sollen sich die Fahrer und Mitfahrer im Anschluss daran gegenseitig Bewerten können.
Die Anwendung soll auf aktuellen mobilen Endgeräten (Smartphones/TabletPCs) lauffähig sein.

2.3 Stakeholder der Anwendung

Zu den Benutzergruppen der Anwendung zählen alle Personen:

• sozialer Netzwerke, die ohne zusätzliche Profilerstellung Dienste anderer Anbieter nutzen möchten
• mit Reisewunsch ohne eigenes Fahrzeug (als alternative zu öffentlichen Verkehrsmitteln)
• mit Fahrzeug, die eine Strecke einmalig oder wiederholt zurücklegen und Sitzplätze im Fahrzeug frei haben
• die Ressourcen finanzieller und oder ökologischer Natur sparsam einsetzen wollen
• ungern alleine Reisen
• spontan Reisen oder Reisen wollen

3 Geschäftsprozesse

Im Folgenden ist ein Geschäftsprozess modelliert, der die grundsätzlichen Funktionen der zu implementierenden Anwendung besser veranschaulichen soll.






Zunächst erfolgt der Aufruf der Applikation über ein Smartphone. Anschließend muss sich der Benutzer an der Anwendung anmelden. Daraufhin befindet er sich im Hauptmenu der Anwendung. Hier wird unterschieden, ob der Anwender eine Fahrt für Mitfahrer anbietet, ob der Anwender eine Mitfahrgelegenheit sucht oder ob er sich Mitfahrgesuche anzeigen lassen will. Sofern der Anwender eine Mitfahrgelegenheit anbieten will, muss er zunächst seine Reisedaten veröffentlichen. Anschließend wird geprüft, ob es passende Mitfahrer mit dem gleichen Reiseziel gibt. Ist dies der Fall, werden dem Fahrer weitere Informationen über den potentiellen Mitfahrer angezeigt und der Fahrer kann mit dem Mitfahrer weitere Details und den Fahrpreis aushandeln. Eine weitere Option ist die Anzeige von vorhandenen Fahrtgesuchen in einem bestimmten Umkreis des Fahrers. Nachdem er den Umkreis entsprechend eingegrenzt hat, werden ebenfalls wieder Details zu den potentiellen Mitfahrern angezeigt und der Fahrer kann mit ihnen Kontakt aufnehmen. Sofern ein potentieller Mitfahrer nach einem Fahrtanbieter sucht, ermittelt das System entsprechende Fahrer. Anschließend kann der Mitfahrer dann Details über einzelne Fahrer aufrufen und mit ihnen Kontakt aufnehmen.

4 Überblick über zu realisierende Anwendungsfälle

5 Funktionale Anforderungen

Im Folgenden werden die Anforderungen beschrieben, die im Rahmen dieses Projektes umgesetzt werden sollen. Hierbei findet eine Unterscheidung zwischen
Pflichtanforderungen, optionalen Anforderungen und nicht funktionalen Anforderungen statt. Sämtliche Pflichtanforderungen müssen bis zum Projektabschluss umgesetzt werden. Die optionalen Anforderungen stellen einen Mehrwert für das Produkt dar, der über die Kernfunktionalität der zu realisierenden Anwendung hinausgeht. Aus diesem Grund müssen diese nur umgesetzt werden, sofern im Projektverlauf noch Aufwand und Budget für die Realisierung vorhanden sind. Grundsätzlich muss im Entwicklungsprozess aber stets berücksichtigt werden, dass die optionalen Anforderungen in einem nachfolgenden Release möglichst problemlos umzusetzen sind. Die nicht funktionalen Anforderungen beziehen sich in erster Linie auf Querschnittsthemen, die die gesamte Applikation betreffen und Qualitätseigenschaften der Anwendung definieren.

5.1 Pflichtanforderungen

In diesem Kapitel sind die Pflichtanforderungen definiert, die in jedem Fall umzusetzen sind. Diese Anforderungen werden zunächst detailliert einzeln beschrieben. Abschließend werden alle Pflichtanforderungen noch einmal tabellarisch zusammengefasst.

5.1.1 Registrierung

Eine zentrale Funktionalität und Vorbedingung für die Nutzung der Anwendung ist die Registrierung am System. Um die Hürde für die Registrierung möglicht gering zu halten, sollen nur essentielle Daten erfasst werden. In der folgenden Tabelle sind die zu erfassenden Daten im Rahmen der Benutzerregistrierung abgebildet:

Feld	Beschreibung	Pflichtangabe	Änderbar
Nickname/Username	Frei wählbarer Benutzername des Anwenders	x	Nein
Passwort	Frei wählbares Passwort des Anwenders Muss mindestens aus 5 Zeichen bestehen Muss mindestens ein Sonderzeichen beinhalten	x	Ja
Vorname	Vorname des Anwenders		Ja
Name	Nachname des Anwenders		Ja
Emailadresse	Email-Adresse des Anwenders	x	Ja
Mobilfunknummer	Mobilfunknummer des Anwenders	x	Ja

Als Benutzername kann der Anwender eine beliebige Zeichenfolge wählen. Der Benutzername muss einen Anwender eindeutig im System identifizieren.

5.1.2 Anmeldung

Sofern ein Nutzer bereits am System registriert ist, muss er sich mit seinen Zugangsdaten (Benutzername und Passwort) jederzeit an der Anwendung anmelden können. Die Anmeldung muss direkt über die Startseite der Applikation möglich sein. Sofern die Anmeldung aufgrund fehlerhafter Angaben nicht funktioniert hat, muss der Anwender hierüber entsprechend informiert werden. Für den Fall, dass der Anwender sein Passwort vergessen hat, muss die Möglichkeit bestehen, dass der Anwender sich ein neues Passwort an eine registrierte E-Mail Adresse zuschicken lässt. Zu diesem Zweck muss auf der Anmeldemaske ein Link integriert werden (Passwort vergessen?). Nach der Eingabe einer E-Mail Adresse wird dem Benutzer ein neues Passwort zugesandt, mit dem er sich am System anmelden kann.

5.1.3. Pflege von Profildaten

Grundsätzlich müssen alle bei der Registrierung angegebenen Daten (mit Ausnahmen des Benutzernamens) über das Profil geändert werden können. Demnach müssen folgende Eigenschaften editierbar sein:

Feld	Beschreibung	Pflichtangabe
Vorname	Vorname des Anwenders
Name	Nachname des Anwenders
Emailadresse	E-Mail Adresse des Anwenders	x
Passwort	Frei wählbares Passwort des Anwenders Muss mindestens aus 5 Zeichen bestehen Muss mindestens ein Sonderzeichen beinhalten	x
Mobilfunknummer	Mobilfunknummer des Anwenders	x
Telefon	Zusätzliche Telefonnummer des Anwenders
PLZ	PLZ der Heimatadresse
Ort	Ort der Heimatadresse
Strasse	Strasse der Heimatadresse
Hausnummer	Hausnummer der Heimatadresse
Führerschein seit	Datum, seit dem der Anwender seinen Führerschein besitzt
Geburtstag	Geburtsdatum
Fahrzeug	Fahrzeugmarke und Modell (Frei Editierbar)
Raucher	Raucher (Ja, Nein)
Umwege	Nimmt der Anwender Umwege in Kauf (Ja, Nein)
Profilfoto	Profilfoto des Anwenders

Für die Pflege der oben aufgeführten Felder muss es einen entsprechenden Bereich in der Applikation geben. Um die Übersichtlichkeit zu gewährleisten ist hier auch gerne eine sinnvolle Gruppierung der Eigenschaften zulässig (bspw. Adresse: PLZ, Ort, Str., Hausnr).

5.1.4 Mitfahrgelegenheiten anbieten

Anwender, die eine Fahrt planen und hierfür eine Mitfahrgelegenheit anbieten wollen, müssen in der Anwendung Details zu ihrer geplanten Route hinterlegen, damit potentielle Mitfahrer ausgemacht werden können. Zu diesem Zweck muss die Oberfläche der Anwendung dem Nutzer die Eingabe der entsprechenden Routendetails ermöglichen.
Folgende Eigenschaften müssen dabei erfasst werden:

Feld	Beschreibung	Pflichtangabe
Start	Genaue Adresse des Fahrers Alternativ muss dieser auch über GPS ermittelt werden können	x
Ziel	Genaue Adresse des Reiseziels (Mind.: PLZ, Ort, Str.)	x
Reisebeginn	Datum des Reisestarts Alternativ muss der Anwender hier auch Sofort auswählen können	x
Freie Sitzplätze	Anzahl möglicher Mitfahrer	x

Nachdem der Anwender alle erforderlichen Daten angegeben hat, kann er seine Fahrt durch die Betätigung eines Buttons veröffentlichen. Ab diesem Zeitpunkt kann diese Fahrt bei der Suche nach Mitfahrgelegenheit mit verwendet werden.

5.1.5 Mitfahrgelegenheit suchen

Das Suchen einer Mitfahrgelegenheit ist die zweite Kernfunktionalität der Anwendung.
Folgende Eigenschaften sind bei der Suche nach einer Mitfahrgelegenheit zu berücksichtigen:

Feld	Beschreibung	Pflichtangabe
Start	Genaue Adresse des Mitfahrers Alternativ muss dieser auch über GPS ermittelt werden können	x
Ziel	Genaue Adresse des Reiseziels (Mind.: PLZ, Ort, Str.)	x
Reisebeginn	Datum des Reisestarts	x

Anhand der oben genannten Kriterien muss die Anwendung die zu den Suchinformationen passenden potentiellen Fahrtanbieter in einer Tabelle anzeigen. Optional ist eine Kartendarstellung zu realisieren, welche die potentiellen Fahrer in ihrer aktuellen Position als Punkte auf der Karte darstellt. Durch Auswählen aus der Tabelle oder der Karte werden die Informationen aus dem Fahrtgesuch und die freigegebenen Profilinformationen des potentiellen Fahrers dem Mitfahrer angezeigt. Zu diesem Zeitpunkt liegt die Auswahl beim Mitfahrer, der anschließend eigenständig (mit Hilfe der Profilinformationen) mit dem Fahrtanbieter Kontakt aufnehmen muss.
Sollten anhand der Routeninformationen keine geeigneten Mitfahrgelegenheiten gefunden werden, muss die Suchanfrage gespeichert werden. Für Fahrer wird daraufhin sichtbar, dass es auf seiner Strecke Mitfahrgesuche gibt, die er ebenfalls eigenständig kontaktieren kann. Die nächste Anforderung konkretisiert dieses Szenario.

5.1.6 Mitfahrgelegenheit anzeigen

Ein Fahrer, der eine neue Fahrt geplant hat, muss die Möglichkeit haben, sich potentielle Mitfahrer in einem ausgewählten Umkreis von 3, 5, 10 und 20 km anzeigen zu lassen. Das Fahrtziel muss hierbei nicht berücksichtigt werden. Diese Information muss der Fahrer selbständig über die Anzeige des Fahrtgesuches erhalten. Diese Anzeige muss wieder die folgenden Eigenschaften beinhalten:

Feld	Beschreibung	Pflichtangabe
Start	Angegebene Startadresse/Position des Fahrers	x
Ziel	Genaue Adresse des Reiseziels (Mind.: PLZ, Ort, Str.)	x
Reisebeginn	Datum des Reisestarts	x

Sofern sich der Mitfahrer dazu entscheidet einen potentiellen Mitfahrer mitzunehmen, da die Reiseziele bspw. identisch sind, muss der Fahrer über das Profil des Mitfahrers die Kontaktdaten ermitteln und entsprechend den Kontakt herstellen.

5.1.7 Mitfahrgelegenheit/Mitfahrgesuch löschen

Entscheidet sich ein Fahrtanbieter, dass er seine Fahrt doch nicht mehr anbieten möchte, so muss er seine Fahrten, bei denen noch kein weiterer Mitfahrer zugeordnet ist löschen können. Die gelöschten Fahrten werden dann nicht mehr bei der Suche nach Fahrtangeboten angezeigt. Auch die Benachrichtigung, wenn ein entsprechendes Mitfahrgesuch eingegeben wird, darf für die gelöschte Fahrt nicht mehr erfolgen.
Auch Mitfahrer müssen ihre eigenen Gesuche löschen können. Wird eine Fahrt angeboten, die auf das gelöschte Gesuch passt, darf an den Suchenden keine Benachrichtigung erfolgen.

5.1.8 Benachrichtigung bei passenden Reisezielen/Fahrtangeboten

Grundsätzlich müssen Fahrer und potentielle Mitfahrer benachrichtigt werden, sobald ein passendes Reisependant für die gewünschte Reise gefunden wurde. Hat ein Fahrer bspw. seine Fahrt angetreten und ein potentieller Mitfahrer meldet eine Stunde später das gleiche Reiseziel an (mit gleichen Reisezielen ist hier die Stadt gemeint), muss der Fahrer hierüber informiert werden, sofern der Reisestart in einem Umkreis von 5 KM zu seiner Route liegt. Die Information muss über die Einblendung eines Hinweises in der Applikation erfolgen.
Umgekehrt muss diese Funktionalität auch realisiert werden, sobald ein potentieller Fahrer das gleiche Ziel wie ein vorhandenes Fahrtgesuche hat. In diesem Fall muss der potentielle Mitfahrer eine Information darüber erhalten, dass ein Fahrer mittlerweile eine Fahrt zum gleichen Reiseziel plant. Wünschenswert wäre in diesem Zusammenhang auch die Darstellung der Information auf einer Karte, sofern die Anzeige darüber realisiert wird.

5.1.9 Bewertungen abgeben

Die Anwendung soll eine Bewertungsfunktionalität beinhalten. Nach Beendigung sollen die Mitfahrer einer Fahrgemeinschaft den Fahrer bewerten können. Der Fahrer soll seine Mitfahrer bewerten können. Das Bewertungssystem soll durch Vergabe von 1 bis 5 Punkten und einen Freitext realisiert werden. Die Anzahl der vergebenen Punkte könnte durch Sterne dargestellt werden.

5.1.10 Passwort zurücksetzen

Hat ein Nutzer Passwort oder Usernamen vergessen, muss die Anwendung eine Möglichkeit beinhalten, dass der Nutzer wieder Zugang zu seinem Account erhält. Es muss sichergestellt werden, dass nur der Ursprüngliche Nutzer seinen Account wieder freischalten lassen kann. Zu diesem Zweck muss der Nutzer seine E-Mail Adresse angeben. An diese Adresse wird dann sein Benutzername und ein neu generiertes Passwort gesendet.

5.1.11 Historie von Benutzern

Die Anwendung muss es ermöglichen, eine Historie der Fahrtangebote und Mitfahrgesuche des angemeldeten Benutzers anzuzeigen. Weiterhin soll die Anzeige an teilgenommenen Fahrgemeinschaften als Historie möglich sein.

5.1.12 Administrative Eingriffe

Die Anwendung muss es ermöglichen einem Administrator Zugriff auf alle Benutzerdaten zu erlauben. Das Passwort muss dabei aus Sicherheitsgründen verschlüsselt hinterlegt sein. Folgende Aktivitäten muss ein Administrator durchführen können:

• Deaktivierung eines Accounts
• Aktivierung eines Accounts
• Passwort neu generieren
• Bewertungen löschen
• Fahrten löschen

Der Zugriff muss nicht über die mobile Applikation selbst realisiert werden. Es ist hier ausreichend, wenn der Administrator die o. g. Aktivitäten auf dem System direkt ausführt.

5.2 Optionale Anforderungen

ID	Beschreibung
O01	Ameldung an der Anwendung über Facebook
O02	Auf der Facebookseite des jeweiligen Users werden Fahrtangebote und –gesuche gepostet.
O03	Die aktuelle Position des Nutzers wird auf der zugehörigen Facebookseite aktualisiert
O04	Darstellung der Fahranbieter/Fahrtsucher auf einer Karte
O05	Anzeige von Fahrtsuchern die sich in der Nähe der Wegstrecke des Fahrers befinden.

5.3 Übersicht über funktionale Anforderungen

ID	Beschreibung
F01	Registrierung
F02	Anmeldung
F03	Pflege von Profildaten
F04	Mitfahrgelegenheit anbieten
F05	Mitfahrgelegenheit suchen
F06	Mitfahrgesuche anzeigen
F07	Mitfahrgelegenheit/Mitfahrgesuch löschen
F08	Benachrichtigungen bei passenden Reisezielen / Fahrtangeboten
F09	Bewertungen abgeben
F10	Passwort zurücksetzen
F11	Historie von Benutzern
F12	Administrative Eingriffe
O01	Ameldung an der Anwendung über Facebook
O02	Auf der Facebookseite des jeweiligen Users werden Fahrtangebote und –gesuche gepostet.
O03	Die aktuelle Position des Nutzers wird auf der zugehörigen Facebookseite aktualisiert
O04	Darstellung der Fahranbieter/Fahrtsucher auf einer Karte
O05	Anzeige von Fahrtsuchern die sich in der Nähe der Wegstrecke des Fahrers befinden.

6 Schnittstellen

6.1 System-Schnittstellen

Im ersten Schritt ist es ausreichend, wenn die Anwendung auf Smartphones mit Android-Systemen nutzbar ist. Langfristig sollen jedoch auch andere Betriebssysteme unterstützt werden. Zudem ist auch eine Web-basierte Variante geplant, über die jeder Nutzer mit einem aktuellen Browser zugreifen können soll. Dies ist jedoch nicht Bestandteil dieses Leistungsumfangs. Um die zukünftige Realisierung jedoch zu ermöglichen, muss die Datenhaltung in einer eigenständigen Backend-Applikation realisiert werden. Der Zugriff auf diese Daten kann dann beispielsweise über Webservices realisiert werden. Diese könnten später dann auch von anderen Systemen genutzt werden.
Des Weiteren müssen Schnittstellen von Android zu Kartenanbietern realsiert werden, um Fahrtanbieter und potentielle Mitfahrer auf einer Karte (bspw. Google Maps) anzeigen zu können.
Ein weiterer Punkt ist noch die Integration der sozialen Netzwerke. Hier muss zunächst die Social Community Facebook mit integriert werden.

6.2 Benutzungsschnittstelle

Da die Zielplattorm der Anwendung aktuelle mobile Endgeräten umfassen soll, muss die Oberfläche problemlos über ein bei Smartphones übliches Touchscreen bedienbar sein.

7 Nicht-Funktionale Anforderungen

ID	Beschreibung
NF01	Die Anwendungsdaten müssen auf dem Server vor unrechtmäßigen Zugriffen geschützt abgelegt werden.
NF02	Die Kommunikation zwischen mobilen Endgerät und Serveranwendung müssen verschlüsselt erfolgen
NF03	Die Kommunikation des mobilen Endgerätes mit dem Kartenanbieter kann unverschlüsselt erfolgen

7.1 Technische Anforderungen

7.1.1 Performance

Anfrage an das Backendsystem
Anfragen an das Backendsystem sollen durch dieses in maximal fünf Sekunden, ohne Netzlaufzeiten zwischen dem anfragendem Gerät und der Serveranwendung, beantwortet werden. Falls die Internetverfügbarkeit Clientseitig nicht vorhanden ist, soll der User durch eine aussagekräftige Meldung darauf hingewiesen werden.

Verarbeiten der Serverresponse
Der Serverresponse mit den entsprechenden Informationen ist in maximal zwei Sekunden nach dem vollständigen übertragen des Response an den Client am Client zu verarbeiten und darzustellen.

Userinteraktion
Jede Userinteraktion in der Clientanwendung, innerhalb der erlaubten Businessprozesse, ist von der Anwendung in maximal einer Sekunde zu verarbeiten und darzustellen.

7.1.2 Skalierbarkeit

Skalierbarkeit des Backends
Da die Akzeptanz und somit die Anzahl der gleichzeitig aktiven Benutzer nicht absehbar ist, muss das Backend skalierbar ausgelegt sein. Das Backend muss minimal Anfragen von 100 aktiven Nutzern in der definierten Antwortzeit bearbeiten können. Das System muss flexibel ausgelegt sein, so dass durch hinzunahme weiterer Hardware, Anfragen von bis zu 10.000 aktiven Nutzern in der vorgegebenen Antwortzeit bearbeitet werden können.
Um Anschaffungs- und Betriebskosten zu sparen soll das System zunächst für 100 aktive Nutzer ausgelegt sein.

Monitoring Backend
Es sind geeignete Monitoringmöglichkeiten zu schaffen, so dass frühzeitig absehbar ist, welche Komponente in kürze einen Engpass darstellen könnte, damit diese Erweitert werden kann, damit die festgelegte maximale Antwortzeit niemals überschritten wird.
Für das Monitoring sind geeignete Schwellwerte zu definieren um frühzeitig Maßnahmen zur Performanceanpassung einleiten zu können.

Skalierbarkeit der Clientanwendung
Wird ein Performance-Engpass am Client festgestellt, so ist durch einen dynamischen Prozess sicherzustellen, dass ausreichend Ressourcen für diese Anwendung vom Clientbetriebssystem reserviert werden. Ist das beschaffen zusätzlicher Ressourcen vom Clientbetriebssystem nicht möglich, so ist der Benutzer durch eine Meldung über den Ressourcen-Engpass zu informieren.

7.1.3 Verfügbarkeit

Backendverfügbarkeit
Die Entwicklung muss stets vor dem Hintergrund stattfinden, dass die Anwendung zu einem späteren Zeitpunkt für die Endkunden hochverfügbar ist. Demnach muss die Anwendung auch in einem Fehlerfall weiter zur Verfügung stehen. Es ist in diesem Zusammenhang jedoch ausreichend die niedrigste Verfügbarkeitsklasse 2 mit einer Ausfallzeit von 87,7 Stunden/Jahr zu unterstützen. Im Desasterfall darf die Mean time to Recover 12 Stunden nicht überschreiten. Die Mean time between failures darf 50 Tage nicht unterschreiten.


Backup
Die Backuplösung muss gewährleisten, dass alle Applikationsdaten bis zu dem Zeitpunkt des Fehlerfalls wieder hergestellt werden können.

7.2 Sicherheit

7.2.1 Datensicherheit

Sämtliche Daten der Anwendung müssen vor unbefugtem Zugriff geschützt sein. Die Übertragung von Daten zwischen dem Client und dem Backend muss verschlüsselt erfolgen. Daten dürfen nicht Massenweise ausgelesen werden können.

7.2.2 Sicherheit des Backends

Das Backend muss vor eventuellen Hackerangriffen geschützt sein. Denial of Service Attacken müssen verhindert werden.

7.2.3 Sicherheit des Clients

Es muss sichergestellt werden, dass der Client ausschließlich mit den definierten Endpunkten kommuniziert. Man in the middle Attacken müssen ausgeschlossen werden.

7.3 Code-Qualität

Abhängigkeiten zwischen Paketen müssen zyklenfrei sein
Die relative Average Component Dependency (rACD) darf höchstens 6% betragen
Die zyklomatische Komplexität von Java Methoden darf den Wert 15 nicht überschreiten
Eine Java Klasse darf maximal 1.000 Zeilen lang sein
Eine Java Methode darf maximal 100 Zeilen lang sein
Trennung von Oberfläche und Businesslogik
Jede produktionskritische Funktion muss mit Testcode überprüft werden
Über „Code Coverage Tests“ soll der Grad der Testabdeckung jederzeit bereitstehen

7.4 Benutzbarkeit

Die Anwendung muss auf Endgeräten mit kleinen Touchscreens bedienbar sein. Weiterhin muss Oberfläche selbst erklärend sein, damit die Nutzer die Anwendung schnell nutzen können und die Akzeptanz hoch ist.
Im nachfolgenden Kapitel werden Skizzen und Beschreibungen einer möglichen Benutzeroberfläche vorgestellt. Diese dienen als Referenzmodell für die Umsetzung der Clientanwendung.

8 Skizze der Architektur und der Benutzeroberfläche

8.1 Skizze der Infrastruktur

Im Folgenden werden erste Skizzen der Infrastruktur dargestellt, die als Richtlinie für spätere Technologieentscheidungen dienen soll.

8.2 Skizze der Benutzungsoberfläche

Profil

Nachdem man die Applikation geladen und sich über Emailadresse und Passwort authentifiziert hat, stehen drei Reiter zur Verfügung.
Der Reiter Profil, der Reiter Suche und der Reiter Route. Auf dem ersten Reiter Profil ist es möglich, seine Daten zu sehen und zu bearbeiten.
In der obigen Skizze findet man einen Auszug der vorhandenen Profildaten. Hat man etwas geändert, kann man seine Änderungen mit dem
SAVE-Button speichern oder das Ändern über den CANCEL-Button abbrechen.




Suche


Suchergebnis
Auf dem zweiten Reiter 'Suche' ist es möglich über Hinreisedatum, Rückreisedatum und Ziel bereits vorhandene, anstehende Fahrten zu suchen. Ob die Fahrten passen,
wird geprüft, indem ein Abgleich mit dem im Profil eingegebenen Startort gemacht wird. Alle Fahrten, die zwischen Startort und Ziel sowie im Zeitraum liegen, werden in einer Liste angezeigt.

In der oberen Ansicht ist ein mögliches Suchergebnis dargestellt. Das Ergebnis einer Suche wird in Listform dargestellt. Zu jedem Sucheergebnis werden mindestens
Reiseantrittsdatum und -uhrzeit, Start- und Zielort sowie die Anzahl freier Plätze angezeigt. Über einen Klick auf eine Zeile der Ergebnisliste verzweigt man in die Fahrt
und erhält weiter Informationen.

Route mit Karte

In der oberen Skizze ist der Reiter 'Route' abgebildet. Hier wird später grafisch abgebildet, ob sich potenzielle Fahrer oder Mitfahrer auf einer vorher definierten Route (im Beispiel von Osnabrück (A) nach Dortmund (B)) befinden. Ähnlich wie im Beispiel Start- und Ziel können weitere Markierungen mit dem Namen der Personen auf der Karte gezeigt werden. Durch einen Klick auf eine Markierung kann dann z.B. Kontakt zur Person aufgenommen werden.

9 Lieferumfang

Zum Lieferumfang der Gesamtanwendung gehört ein lauffähiger Client für die Anwendung auf dem Betriebssystem Android. Ebenso muss eine lauffähige Backendsoftware, die mit dem Client kommuniziert geliefert werden. Für den Client und die Backendsoftware muss ein Handbuch geliefert werden, welches den Umgang mit dem System erklärt. Des Weiteren ist ein Backup und Betriebskonzept für die Anwendung zu liefern.
Ein Prototyp des Clients muss geliefert um die Machbarkeit des Konzeptes zu zeigen.

10 Abnahmekriterien

10.1 Voraussetzung für die Abnahme

Voraussetzung für die Abnahme sind die folgenden Bedingungen:
Der Prototyp der Clientapplikation ist zum angegeben Liefertermin in einem stabil lauffähigen Umfang zu liefern. Die Grundlegenden Businessprozesse werden im Groben zu erkennen sein.
Alle nichtfunktionalen Anforderungen müssen erfüllt sein und ihre Erfüllung muss durch entsprechende Tests nachgewiesen werden.
Alle nichtfunktionalen Anforderungen müssen erfüllt sein. Ihre Erfüllung ist durch entsprechende Tests nachzuweisen.
Durch Definition und Durchführung entsprechender Testfälle ist die korrekte Umsetzung aller Anwendungsfälle nachzuwesien. Voraussetzung für die Abnahme ist, dass mindestens 95% der Anwendungsfälle korrekt umgesetzt sind.

10.2 Durchführung und Aufbau der Testfälle

Für jeden spezifizierten Anwendungsfall muss mindestens ein Testfall definiert werden. Besteht der Anwendungsfall aus mehr als einem Hauptszenario, sind ebenfalls für die Alternativszenarien Testfälle zu erstellen. Der grundsätzliche Aufbau eines Testfalls orientiert sich dabei an folgender Vorlage, welcher jedoch verfeinert werden kann:

Anwendungsfall
Szenario
Voraussetzung
Eingangsparameter
Durchzuführende Aktion
Erwartetes Ergebnis
Tatsächliches Ergebnis